TIP-1027 Review

protocolVersion → T5

Frontmatter says protocolVersion: TBD. Should be T5.

Security / Correctness Issues

1. Paused-token bypass on DEX-recipient path is a meaningful weakening of pause semantics. The TIP explicitly allows swapExactAmountInTo(..., DEX_ADDRESS) to succeed when tokenOut is paused, with the rationale that pause is enforced on withdraw. But this means a user can acquire economic exposure to a paused token via internal DEX balance. If an issuer pauses a token expecting to freeze all new acquisition, this is a bypass. The TIP acknowledges this is intentional, but it deserves a more prominent callout in the spec — possibly a dedicated "Security Considerations" section — so issuers understand the trade-off.

2. Synthetic zero-value Transfer + TransferWithMemo events are dangerous for indexers. When recipient == DEX and the swap is fully internally funded, the TIP requires emitting zero-value events on tokenIn to preserve the memo. Off-chain systems (explorers, accounting tools, compliance) will index these as real token movements. Consider:

   • Using a distinct event type (e.g., MemoAttached) instead of a zero-value Transfer
   • Or at minimum, documenting that indexers MUST ignore zero-value Transfer events from DEX-recipient paths

3. Sender identity in TIP-403 checks on external-recipient path. The spec says output settlement uses ITIP20(tokenOut).transfer(recipient, amountOut) — a transfer from the DEX. The DEX is the sender for TIP-403 purposes. This means:

   • The DEX (not the caller) must be an authorized sender
   • If the DEX is blacklisted as sender on tokenOut, all swap-and-send to external recipients fails
   • This is probably correct, but should be stated explicitly so it is not misimplemented as a caller-is-sender check

Suggested changes

-protocolVersion: TBD
+protocolVersion: T5

👁️ Cyclops Review

PR #3016 adds a draft TIP for swap-and-send functions (target: T5). The diff is docs-only, but the spec makes security claims about the existing T2 StablecoinDEX that are demonstrably false. Three verified findings describe real pre-existing bugs in live T2 code that this spec's rationale relies upon.

🚨 [HIGH] StablecoinDEX swaps and orders bypass access-key spending limits

File: crates/precompiles/src/tip20/mod.rs:616-685

DEX input debits never enforce access-key spending caps. _transfer_from() does not call authorize_transfer(), and internal-balance debits have no keychain accounting. A compromised access key can drain any DEX-approved or internal balance far beyond its configured cap. TIP-1027's WithMemo design would widen this surface by explicitly using transferFromWithMemo on the input leg.

Fix: Charge access-key spending limits in _transfer_from() whenever from == tx_origin, and mirror in the DEX internal-balance debit path.

✅ Verified with test (test_access_key_limit_bypass_via_dex_swap).

👁️ Cyclops Review

This PR adds a Draft TIP-1027 specification for swap-and-send. No runtime code is changed. The spec is internally consistent, but the audit surfaced pre-existing issues that this TIP either amplifies or relies on incorrectly.

🚨 [SECURITY] Sender-blacklisted makers can still trade through pre-escrowed orders

Severity: Medium | Status: Verified with passing test
File: crates/precompiles/src/stablecoin_dex/mod.rs:655-724

cancel_stale_order() correctly classifies an order as stale once the maker loses sender authorization, but fill_order() / partial_fill_order() never revalidate that condition. A sender-blacklisted maker's pre-escrowed orders can still be filled, crediting the maker with the opposite asset which they then withdraw. TIP-1027 lines 133–141 assume placement-time policy checks are sufficient for existing maker-fill credits — this is incorrect after post-placement policy changes.

Recommended Fix: Recompute the stale condition before matching any order. If the maker is no longer authorized as a sender on the escrowed token, skip or auto-cancel the order. Quote paths should also exclude stale liquidity.

⚠️ [ISSUE] Access-key spend limits bypassed on DEX external-funding path — TIP-1027 recipient amplifies to direct theft

Severity: High (once TIP-1027 is implemented)
File: crates/precompiles/src/tip20/mod.rs:616-685

TIP-1027 claims the new *To functions reuse the same input-debit logic (a "settlement-only change"). However, the current transfer_from / transfer_from_with_memo paths used by the DEX never consult AccountKeychain spend limits, while transfer() and system_transfer_from() do. Today this is an over-broad self-trade. With TIP-1027's recipient parameter, a compromised limited access key could spend the user's full DEX allowance and redirect output to an attacker address.

Recommended Fix: Add AccountKeychain::authorize_transfer() / check_and_update_spending_limit() to the transfer_from and transfer_from_with_memo code paths before TIP-1027 is implemented.

⚠️ [ISSUE] Post-pause bids create fresh paused-token positions through existing fill path

Severity: Medium
File: crates/precompiles/src/stablecoin_dex/mod.rs:421-438

TIP-1027 adds a pause check on the DEX-recipient path to prevent paused-token position buildup. However, existing place() never checks paused() on the base token, and fill_order() credits paused-token internal balances without a pause gate. The invariant TIP-1027 claims to establish does not hold for existing paths.

Recommended Fix: Extend the pause gate to place() for the base token and block swap input consumption from internal paused-token balances.

IMO the "credit to internal balance" functionality should be its own function (maybe swapAndDeposit?) instead of a special case where you pass the DEX address as the recipient.

Right now, depending on whether you pass the DEX address or a regular address, the function does two different things with different policy checks, no actual token transfer, the memo gets attached to a different leg, and TIP-1028 doesn't apply.

Splitting it into two functions means each does one thing clearly. swapAndSend always transfers to the recipient, and swapAndDeposit doesn't need a memo since nothing is moving externally.

If swapAndDeposit is useful, I think we could consider it for another TIP.